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This case study discusses implementing a Bring Your Own Token (BYOT) 
solution with support for self-provisioning and management options to enable 
users to provision digital identities used for strong authentication and signing. 


Abstract 


Smart cards are a good way to enable strong authentication to enterprise network and applications 
because they provide identification, authentication, and the ability to store cryptographic key information 
on a card using the embedded microchip and memory. Enterprises can provision smart cards with a 
digital identity, in the form of a X509 certificate uniquely associated with a user, to enable smart card 
login to servers and mutual TLS authentication to services. Traditionally, hybrid cards that provide both 
the proximity card and smart card functionalities are used for this purpose so that users can have a single 
card for facility access and strong authentication to IT servers or applications. 


There are some limitations and challenges with using a single card as both proximity and smart card. 
Proximity cards can generally preprovision in bulk because the association of the user identity to the 
proximity ID can be done after the card is assigned to a user. But for the smart card, the X509 certificates 
provisioned to the smart cards contain the user information that must be known at provisioning time. 

This slows down the provisioning process. There are also other challenges related to issuing temporary 
replacement cards for lost cards. 


This white paper describes the Cisco solution to replace traditional hybrid smart cards with a Bring 
Your Own Token (BYOT) model, to overcome the limitations and challenges with traditional smart card 
solutions. Our solution enables users to bring their own USB tokens that are compatible with Personal 
Identity Verification (PIV) and Chip Card Interface Device (CCID) standards, to self-provision digital 
identities needed to enable strong authentication, signing, and other cryptographic functions. 
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Introduction 


The idea of incorporating an integrated circuit chip onto a plastic card was first introduced by two 
German engineers in the late 1960s, Helmut Grottrup and Jürgen Dethloff. A smart card! is essentially 
a plastic card with an embedded integrated circuit chip. Smart cards come in many different types 
and dimensions and contact and contactless forms. Their physical characteristics, electrical interface, 
transmission protocols, crypto mechanisms, etc., are defined in the ISO/IEC 7810 and ISO/IEC 7816 
standards. At their core they provide a tamper-resistant secure crypto processor and secure file 
system which communicates with external services using a card reader. The cryptographic key 
material and digital certificates are securely generated and imported to the chip. 
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Figure 2: Smartcard pinout diagram 


Figure 1: Smart Card Dimensions 


Smart Card Use Cases 


One of the most widely adopted and successful use cases for smart cards is for mobile 
communications with the Global System for Mobile Communications (GSM)* network and the 
Subscriber Identity Module (SIM). Another use case is in banking and retail with EMV Chip cards‘ that 
implement the Chip and PIN or Chip and Signature schemes for securing credit transactions. The focus 
of this white paper is the use case of smart cards for IT applications to enable strong authentication, 
signing, and encryption. 


The traditional use of smart cards at large enterprises involved the use of hybrid cards that provide 
both the physical access proximity card and the logical smart card functionality. This combined the 
two functions onto a single card for enterprise facility access and strong authentication to information 
systems. The digital identity certificates for strong authentication are either provisioned on premise in 
the badging office using kiosks or using third-party provisioning partners. 


1 https://en.wikipedia.org/wiki/Smart_card 
? https://en.wikipedia.org/wiki/GSM 
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CCID and PIV Standards 


The Chip Card Interface Device (CCID)° standard, defined by the USB standards work group in March 

2001, specifies the protocol and requirements for a smart card to be connected to a computer via a card 
reader using a standard USB interface, without the need for each smart card manufacturer to provide its 
own reader or protocol. The latest revision of CCID (1.1) was released in April 2005. 


The Personal Identity Verification (PIV) standard was published by National Institute of Standards and 
Technology (NIST) in February 2005 with FIPS 201 document. This specifies the architecture and technical 
requirements for a common identification standard to improve the identification and authentication of 
federal employees and contractors for access to federal facilities and information systems. The latest 
revision of PIV (FIPS 201-2)° was published in August 2013. 


The PIV standard specifies the requirements for standard slots or data objects in smart cards listed in the 
following table. The commonly used slots are 9A and 9D. 


04 PIV Secure Messaging Never 

9A PIV Authentication Once per session 
9B PIV Card Application Administration Never 

9C Digital Signature Every use 

9D Key Management Once per session 
9E Card Authentication Never 

82, 83, 84, 85, 86, 87, 88, 89, 8A, 8B, Retired Key Management Key Once per session 


8C, 8D, 8E, 8F, 90, 91, 92, 93, 94, 95 


Table 1: List of Standard Slots 


These two standards have played a significant role in standardizing and simplifying the use of smart cards 
on computers for various use Cases. 


Limitations with Traditional Smart Cards 


Most of the limitations with traditional smart cards concern the physicality of the smart card. Programming 
the physical and logical portions of the card requires setting up kiosks in badging offices or using a third- 
party provisioning service provider. The third-party solution introduces a delay between requesting a 
badge and actual receiving a working, usable badge. It does, however, work fairly well for full-time remote 
workers. Conversely, a kiosk in a badging office on a company’s campus does not work well for full-time 
remote workers. 


Another challenge is dealing with lost or misplaced smart cards. The same challenges in initial provisioning 
of a smart card exist, with a user having to visit a badging office or wait for their new badge to be shipped. 
Tangentially related, if a strong entity for authentication is provisioned to the smart card that the employee 
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relies on for logical access to their workstation, forgetting the badge at home and arriving at the workplace 
can leave the employee without many good options. Most companies have some means to provision 
temporary badges for physical access, but what about logical access? 


Yet another challenge with the traditional smart card program is the need for the card reader and the 
support for necessary driver or middleware on the host operating system to interact with the smart card. 
Support for smart cards is not consistent across different operating systems. While the native support for 
smart cards is good on Microsoft Windows, a middleware driver such as OpenSC” or additional vendor- 
specific software is required to be installed on the MacOS and Linux to interact with smart cards. 


Evolution of Strong Authentication at Cisco 


Cisco has been using some form of strong authentication since 1997. This has evolved over the years as 
shown in the following timeline. 


Started advocating IT SmartBadge Token Provisioning 

for SmartBadge Program Pilot Partner informs EOS 
Safeword Premier SmartBadge Admin Token & Crypto ID (BYOT) 
Access(SPA) deployed for GOV Group SmartBadge goes live 
for VPN Access Program Live 


Figure 3: Timeline of Strong Authentication Solutions at Cisco 


Safeword Premier Access 


In 1997, Cisco deployed the Safeword Premier Access (SPA) product to enable users one-time password 
(OTP)-based authentication to protect sensitive and privileged access operations. This was used to protect 
VPN access to Cisco networks, SSH access to remote servers, and enabling root access (sudo). 


The first iterations of this service offering were not self-service and required Cisco users to call into 
Cisco’s internal helpdesk, the Global Technical Response Center (GTRC) for help with their tokens. SPA’s 
OTP system was an event-based system (HOTP)® and therefore the counter between the clients and 
servers could get out of sync. Another problem was the counter for a particular user’s token was required 
to be kept in sync between all the backend SPA servers, which was problematic when load was high and 
due to network latency. 
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GGSG Smart Card Program 


Around 2003, the InfoSec team at Cisco, which was responsible for the operation of the SPA servers at 
that time, began to evangelize a new combined physical and logical access token to replace the aging 
infrastructure and close some vulnerabilities. No executive was willing to pay the estimated one million 
USD to replace all employee’s badges, but a smaller group within Cisco, the Global Government Support 
Group (GGSG) was identified as a potential candidate for rollout of such a program in 2007. A Card 
Management System (CMS) was purchased from Actividentity’ and approximately 300 users’ badges 
were replaced with the new HiD-sourced PIV-C smart card. 


Unfortunately, mistakes were made and the complexity, knowledge, and effort required to maintain the 
CMS system was vastly underestimated. Proper resourcing was not assigned and ultimately the program 
failed when the configuration broke and our limited resources were overwhelmed with user support 
requests. 


Corporate Smart Card Program 


Around 2012 Cisco initiated a corporate smart card program called Smartbadge. The program relied on 
outsourcing the CMS and printing of the badges to a third party, IDonDemand (IDOD) which was later 
acquired by Identity’? as a managed service. Cisco still maintained and operated the PKI, requiring the use 
of an IDOD product called Bouncer to bridge the communication between IDOD and the Microsoft CA. 


Due to the cost of the managed service, a portal was developed to handle enrollment of users and cross- 
charging of departments for the replacement badge. The barrier for entry was $85 per year and, at the 
behest of the Cisco PKI team, was a prerequisite for also receiving an S/MIME certificate. This was meant 
to drive adoption of the Smartbadge because clients throughout the company had requested S/MIME 
certifications for many years prior. 


Ultimately, 1815 Cisco users participated in the badge replacement program at the S85 per year cost. 
Many users did not finish the activation step of enrolling their new Smartbadge with the Physical Access 
System (PAC), Lenel, and simply spent the money to get a S/MIME cert so they could sign or encrypt their 
emails. 


During the same period, the Cisco PKI team evaluated Yubikey NEO as another option for a logical access 
token as a proof of concept. The PIV applet was provisioned with some test certs and authentication to 
various service was secured using them to prove out the concept. 


AdmintToken program 


An InfoSec policy change in 2015 requiring a hardware token for Cisco administrative accounts on 
Microsoft Windows machines necessitated the development of a method to request and manage the new 
tokens. This was a natural second step following in the footsteps of the Smartbadge program. For this 
program, the SafeNet eToken was picked as the supported hardware token. 


The provisioning and shipping of the tokens was still handled by the IDonDemand managed service with 
the same Cisco-run PKI on the back end. A separate portal was developed to manage the AdminToken 
requests, handling cross charges, approvals, and termination. 


ps://www, hidglobal.co prod 
1 https://www.identiv.com/services/ 
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Need for a new solution 


Several years after rolling out the Smartbadge and AdminToken programs, the adoption rate was still very 
small. This was mainly due to the expense and usability issues associated with both programs. In February 
2018, IDonDemand informed Cisco that the managed service would be terminated in January 2019. 


Therefore, in early 2018 Cisco embarked on a new program called CryptolD. The program, dubbed Bring 
Your Own Token (BYOT) was designed to enable Cisco employees, contractors or third parties to acquire 
their own tokens and provision a digital identity certificate. Cisco wanted this solution to be entirely self- 
service, avoiding the management overhead of cross-charging for hardware, and ultimately reducing 
support cases by empowering users to fix their own issues. The CryptolD program would replace the 
previously supported solutions with a single consolidated platform with support for different certificate 
types, such as UserToken, AdminToken and S/MIME. 


Solution Description 


The CryptolD solution is compatible with any USB hardware token that supports the Personal Identity 
Verification (PIV) and Chip Card Interface Device (CCID) standards. However, to ensure security and 
usability, we onboard different token models only after a thorough evaluation. 


Functional Requirements 
The following are the requirements for the proposed system. 
= Ability to associate the token to a unique user 
= Ability to control what token models and firmware versions are allowed to be registered 


= Ability to control and manage the user and admin PIN policies such as retry count, length 
requirements, lockout settings, etc. 


= Ability to control cryptographic algorithms and mechanisms permitted to create key materials 
and certificates 


= Ability to ensure and attest that the cryptographic key materials are created on the hardware 
token and are not exportable 


= Ability for users to create authenticated and attested provisioning requests and self-provision 
tokens with digital identities 


= Ability for users to revoke or replace certificates 
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High-level Design 


The core components of the system are the CryptolD portal and the CryptolD client. These components 
enable the BYOT and self-provisioning aspects of the solution. The components interact with other existing 
IT systems such as Directory Services, single sign-on and Certificate Authority servers for the provisioning 
of digital identities. The following figure illustrates the high-level system architecture of the CryptolD 
solution. 


Directory 


Services / SSO HSM API 


Certificate 
Authority 


OCSP/CRL 


Figure 4: CryptolD System Design 


Token Selection Criteria 


One important aspect of the BYOT approach is the decision process around which token vendors and 
models should be supported. The CryptolD solution is designed to be generic and extensible, and to 
work with any of the tokens that meet some of the basic requirements for the program. Cisco established 
a process and checklist to evaluate the hardware tokens against the core requirements for the CryptolD 
program. Appendix F" provides a sample evaluation form. 


Based on our evaluation results, the Yubico YubiKey tokens proved to be reliable, low cost, and relatively 
easy to use. The Yubikey tokens meet all our core requirements for PIV functionality and also provide 
other applets such as OTP and FIDO2. The OTP and FIDO2 applets can be configured with Cisco’s Duo 
single sign-on system for second factor authentication. Cisco employees no longer have to chain together 
several different solutions to fit many use cases. Instead, they can entitle, enable and use one token for 
many security controls. 


Advantages 


The following are some of the advantages of the CryptolD solution. 


No external vendors involved in the provisioning process 


No vendor lock-in for hardware tokens; the solution is generic and extensible 


Flexibility to allow users to bring their own tokens to provision digital identities 


No need to revoke or replace identities when a badge is misplaced or lost 


Quick turnaround through self-provisioning 


Reduced cost and overhead 


" Appendix F: Sample Token Selection Criteria Checklist Form 
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CryptolD Use Cases 


The CryptolD solution currently supports provisioning of three different digital identities associated with a 
user. Support for additional identity types can easily be added. 


AdminToken 

= Issued to: Cisco Admins (CN=admin_userid@cisco.com) 

= Purpose: Administrative access to remote servers (smart card login) 
UserToken 

= Issued to: Cisco Employees/Contractors (CN=userid@cisco.com) 

= Purpose: Strong Authentication (Smart card login or TLS client authentication) 
SMIME 

= Issued to: Cisco Employees/Contractors (CN=userid@cisco.com) 

= Purpose: Sending signed/encrypted emails 


Users have complete control to request and manage their CryptolD certificates. They can request new 
certificates and manage their lifecycle, including download, install and revocation. The CryptolD portal 
automatically publishes issued certificates to Active Directory. The portal also automatically revokes the 
certificates of any inactive Cisco employees. 


Admin/User Token Use Cases 


Both the AdminToken and UserToken identities are installed on the same slot (9A) in the token. Therefore, 
users who need both AdminToken and UserToken require two different hardware tokens to work natively 
and comply with the PIV standards. The AdminToken and UserlToken CryptolD certificates, installed on 
token slot 9A, can be used for different strong authentication use cases such as the following: 


Smart card logon 
= The CryptolD certificate on slot 9A can be used to log on to Windows servers 
= Windows natively supports smart cards that comply with PIV standards 

SSH authentication 


= The CryptolD certificate on slot 9A can be used to strongly authenticate via SSH to a server running 
OpenSSH 


= There are many considerations and best practices for using the certificates and/or keys stored on a 
token in slot 9A" outside the scope of this white paper. 


TLS client authentication 


= The CryptolD certificate on slot 9A can be used to strongly authenticate to a client server properly 
configured to accept certificates as an authentication option 


= Guides for configuring TLS client certificate authentication on popular client servers such as Apache 
and Nginx are readily available on the internet 


= For client setup on the Chrome, Internet Explorer, Edge, and Safari browsers, very little is needed on 
Windows/Mac OS. However, Firefox requires additional configurations on any platform as detailed in 
Appendix D? 
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S/MIME Use Case 


The Secure/Multipurpose Internet Mail Extensions (S/MIME)"* has been in existence since approximately 
1997 and is widely supported in mail clients for sending signed and encrypted email. The CryptolD S/MIME 
certificate can be downloaded as PKCS#12'"° file that contains the private key, associated certificate, and 
certificate chain (Subordinate CA and Root CA certificates). It can either be imported to the token slot 9D or 
directly on the computer/mobile device’s key store. This certificate can be used for signing and encrypting 
emails. 


Implementation Details 


Overview 


The CryptolD portal and client tool were developed to give Cisco employees complete control over 
provisioning and managing their digital identities. The user procures any approved token (currently, Yubikey 
Series 4 or 5 with firmware v4.3.5 or greater), logs in to the CryptolD Portal and follows the instructions to 
provision the required CryptolD certificate. 


If a user needs both AdminToken and UserToken certificates, they must buy two tokens because both of 
those certificates are installed on slot 9A to work natively and comply with the PIV standards. 


AdminToken and UserToken Provisioning 


The CryptolD client provides a generic interface for the users to interact with the hardware tokens. It 
abstracts the token vendor specific middleware tools with the help of a standard client interface that 

is extensible to implement wrappers around the different supported token types. Currently it provides 
extensions for both yubico-piv-tool and ykman, provided by Yubico, to interact with the Yubikey tokens, 
through a simple command-line interface. 


To provision a new Yubikey, the user downloads the client, runs the client tool, and chooses option #1 
to generate a new CryptolD client request. The resulting Base64-encoded CryptolD Client Request’? is 
displayed to the user for pasting back into the CryptolD Portal. The CryptolD design takes two steps to 
ensure the integrity and confidentiality of the request. We use the Attestation feature!” of the Yubikey 
(firmware v4.3.5 or higher) to ensure the keypair that creates the Certificate Signing Request (CSR) 
was generated on the Yubikey. We authenticate the user to our Active Directory (AD). 


The Yubikey PIV Attestation feature shows that a certain asymmetric key has been generated on device 
and not imported. This is accomplished by signing a specially crafted Certificate Signing Request 
(CSR). The CSR is created from the newly-generated asymmetric key and includes specific extensions 
to capture the token details and then signed by the attestation certificate in slot f9. The attestation 
certificate comes pre-installed on the Yubikey and is issued by Yubico PIV CA. The CryptolD client 
includes this signature in the Base64-encoded CryptolD Client Request data. 
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Because the CryptolD Client Tool is entirely separate from the CryptolD Portal and is run 
asynchronously, we authenticate the user to our Active Directory (AD) and include the username in the 
Base64-encoded CryptolD Client Request and on the attested Certificate Signing Request (CSR). The 
username in the request is verified against the username in the CSR and the user who logged in to the 
portal, to prevent any forgery. 


Another precaution the CryptolD Portal takes is verifying the Yubikey token model and firmware through 
a whitelist. As the Attestation feature is only available on Yubikey firmware greater than 4.3.5 that is 
checked. Also, Yubico released a security advisory on 2017-10-16 about firmware versions lower 
than 4.3.5 producing weak RSA keys'®. The PIN policy is also checked to ensure it is set to “Never:01” 
which disables the Yubikey requiring a PIN except on first use and allowing the application to cache it. 


The provisioning process includes three high-level tasks. 


1. User downloads the CryptolD client and runs the “Generate CryptolD Provisioning Request” 
command. The client performs the following steps in the background to generate an attested 
CryptolD provisioning request. 


a. Verify Yubikey token connected 

b. Verify PUK requirements 

c. Verify management key requirements 

d. Verify PIN requirements 

e. Authenticate user to AD 

f. Generate keypair on token 

g. Generate CSR from keypair on token 

h. Attest keypair on token 

i. Build Base64-encoded CryptolD provisioning request and display to user 
2. User submits the attested CryptolD provisioning request data to CryptolD portal. The portal 

performs the following steps to validate and issue the CryptolD. 


a. Verifies userlD for logged-in user and userName in request match 
b. Verifies Certificate Signing Request (CSR) 

c. Verifies Attestation in request 

d. Submits CSR to Certificate Authority (CA) over REST 

e. Receives X509 Certificate from CA 

f. Provisions X509 Certificate to user's AD account 


3. User installs the X509 Certificate into the token’s PIV authentication slot (9A) 
a. User downloads X509 Certificate 
b. User installs X509 Certificate using CryptolD client 


S/MIME Provisioning 


The S/MIME certificates can be provisioned directly on the CryptolD portal. The process does not require 
any request data to be generated using the CryptolD client. Cisco escrows the private key associated with 
the user’s S/MIME certificates for legal purposes. So, the private key and CSR for the S/MIME certificate 

is generated securely on the CryptolD server using a Hardware Security Module (HSM) and its underlying 


1° bttps://www.yubico.com/support/security-advisories/ysa-2017-01/ 
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True Random Number Generator (TRNG)'®. The CSR is then submitted to the CA to issue the cert and 
finally a P12 file is created. The P12 is protected using a secure random password. Both P12 and the P12 
password are encrypted using an AES-256 key before storing in the database. The AES-256 key used for 
the encryption is securely generated on an HSM and marked non-exportable, non-extractable. 


The user can download the P12 file, and the associated password from the CryptolD portal, and import it 
either to their computer/mobile key store, or to their YubiKey slot 9D. 


All the S/MIME certificates provided through the CryptolD portal have a 2-year validity period. This short 
validity period was chosen because the certificates are provided in a portable format (P12) purely in 
software. The user is emailed through an automated process to be notified their certificate is expiring in 90 
days, 60 days, 30 days, 7 days, and 1 day. 


Deprovisioning 


Users can revoke their own certificates and a background task revokes certificates for inactive Cisco 
employees, querying Cisco’s AD nightly. If a user loses their token, we rely on them to notice, return to the 
CryptolD portal and revoke the credential. They must revoke the current credential in order to procure a 
new one; that is, users cannot have more than one active AdminToken, UserToken, or S/MIME. 


OTP Seed Provisioning 


Yubikeys come with an OTP applet? and the seed preprovisioned to the YubiCloud?! for authentication. 
Cisco uses Duo”? for our SSO infrastructure. Duo supports Yubikey OTP as a second factor authentication 
mechanism but it does not use the YubiCloud as a backend authentication service. Instead it requires the 
Yubikey OTP tokens to be individually registered with the OTP seed. Duo provides an API for enabling this 
provisioning. The CryptolD Client Tool was enhanced to generate this OTP seed and provide a Base64- 
encoded request?’ as output to be copied by the user into the self-service Duo registration portal’. 


Similar to the AdminToken and UserToken provisioning process, the user initializing their OTP seed is 
authenticated to Cisco’s Active Directory and their username is included in the Base64-encoded request 
data. Because the Yubico tools provided no way to protect the OTP seed, an additional step to encrypt the 
seed value to the CryptolD Portal’s RSA Public key was taken as a security measure. 


Libraries, Tools, IDEs 


The CryptolD portal was developed entirely using Java, targeting the Java v8 JRE. The team makes 
extensive use of the IAIK JCA/JCE Toolkit? as a crypto utility. The IAIK Toolkit is very similar to the more 
popular, open-source BouncyCastle”® but has better documentation. The IDE used was the excellent 
Eclipse Foundation?” or a variation of. 


The CryptolD Client bundled the yubico-piv-tool*® compiled for Windows, Linux, and MacOS target client 
platforms. See Appendix A for detailed commands used. 


19 https://en.wikipedia.org/wiki/Hardware_random number generator 
20 . = . 


https://developers.yubico,com/OTP/OTPs Explained. html 
21 https://www.yubico.com/products/services-software/yubicloud/ 
2? https://duo.com/ 
23 H . 
2% https://disco.cisco.com/ 
3 https://jce.iaik.tugraz.at/sic/Products/Core Crypto Toolkits/JCA JCE 
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Development Time 


Two people from the Cisco PKI team developed CryptolD over four months to get to the v1.0 release. A 
test version was ready in ~2 months for a limited release scope (10-15 users) and much positive feedback 
was received. This timeline was greatly compressed because of the various lessons learned from the 
previous years with the various strong authentication programs and the team’s familiarity with operating a 
PKI. CryptolD is now at v1.4 and has had very little in terms of upkeep and maintenance for the developers. 
Future enhancements have been thought through and are covered in the next section. 


Future Enhancements 


Other Token Types 


Hardware security keys like those from Feitian??, PIVKey*°, and SafeNet eToken?! would be nice to support 
in addition to YubiKeys, giving Cisco users many form factor choices for what they want to use. The 
primary roadblock to supporting more token types is the development and support of the CryptolD client. 
Also, the attestation feature is something unique to the YubiKeys Cisco would miss out on implementing 
support for other token types. This limitation could be partially overcome by the CryptolD client 
implementing a similar feature in software. 


Platform Native CryptolD Tools 


For OTP seed provisioning, a standalone utility was developed in Python to utilize the ykman Python 
libraries*? and then compiled to target the client platforms using pyinstaller?’. This standalone utility was 
then signed with the platform appropriate code sign utility for distribution. A future enhancement to the 
CryptolD client tool would be to rewrite it in Python and compile a platform-specific version as well. 


Alternatively, a GUI version developed using Electron*4 would be attractive to those employees not 
comfortable with command-line utilities. Advantages of the thick client or platform-specific binaries would 
include the elimination of a copy and paste step from the client to the portal; clients could communicate 
directly to the portal via APIs. 


S/MIME Certificates for Vanity Email Aliases 


With the development of CryptolD, Cisco added the option of a free S/MIME cert to any Cisco employee 
using their username@cisco.com email address in both the Email (E) relative distinguished name field of 
the SubjectDN°* and the rfc822 subject alternative name? field. Almost immediately, we had requests to 
support vanity email aliases that Cisco users had procured over the years. Supporting these vanity email 
aliases would be a good feature to include in the future. 


2° https://www.ftsafe.com/Products 


°° https://pivkey.com/ 

31 . ai i . . b 
22 https://github.com/Yubico/YubiKey-manager/tree/master/ykman 
33 https://www. pyinstaller.org/ 


* https:;//electronjs.org/ 
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S/MIME Certificates for Mailers 


Cisco employees receive many emails from mailing lists and replies to these emails go to a group of 
people. We have received a few requests for these mailers to be assigned S/MIME certs so the emails can 
be signed and look more “official.” To date we have been able to support these requests in a very manual 
way by going directly to the CA to issue the certs but we want to enhance the CryptolD portal to allow 
owners of mailers to “enroll” on behalf of their various mailers. This would let us track these certificates, 
owners could receive expiry notifications, and certs would be revoked if mailers were deleted or owners 
left Cisco. 


UserToken for Generic Accounts 


AD generic accounts are generally used by automated scripts or processes to authenticate with remote 
resources. It would be ideal to strongly authenticate these accounts with an X509 certificate much like 
we can strongly authenticate regular Cisco users. Cisco has a web application for owners to easily 
manage accounts owners, members, and passwords. The CryptolD portal could tie into this API to ensure 
UserTokens were being requested only by generic account owners. Also, this would let us keep track of 
these certificates, owners could get expiry notifications, and certs would be revoked if generic accounts 
were deleted or owners left Cisco. 


Lessons Learned and Key Considerations 


Token use in VMware 


Requiring Windows administrators to login with their PIV-enabled YubiKey quickly uncovered the fact that 
many of Cisco’s Windows admins are using a different OS than Windows on their workstations (MacOS, 
Linux, etc.). When attaching the YubiKey to a virtual machine (VM) in VMware the default behavior is for 
that USB device to show as “shared.” Yubico had a solution involving modification of the VMware VMX 
file for the VM%°, marking the Yubikey as dedicated to the VM and allowing Windows to access the PIV 
authentication slot (9A) on that YubiKey for authentication to the user’s privileged administrator account. 


MacOS Catalina Issues 


A recent problem is Apple’s release of MacOS Catalina and the disabling of 32-bit applications. Both the 
CryptolD client tool and the standalone platform-specific compiled binary for the OTP seed provisioning 
have encountered problems with various client installs of the new MacOS. More investigation is needed 
and possibly new releases of these tools. 


Involvement of Infrastructure Teams 


When considering establishing a similar program at your company to offer hardware-based, strong 
identity certificates, it is wise to involve your AD and PKI technical points of contact early. Cisco was 

lucky in that the developers on CryptolD were the PKI team, so integration was easy. Having a good 
working relationship with the AD team helped integrations, along with a generic account that had elevated 
privileges to publish certificates to all user and administrator accounts in AD. 
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Return on Investment (ROI) 


Token Reliability 


The YubiKeys have proven to be much more resilient and harder to break. Designed to be added to 
keyrings, they are built for quite a bit of abuse and we are not getting very many reports of damaged 
tokens. We have only received reports of couple of faulty YubiKey tokens in the last year, compared to 
more than 50 token replacement requests per year with the old AdminToken program. 


Token Consolidation 


The multiprotocol support provided by YubiKey is very helpful to enable the same hardware token to be 
used for different use cases. Apart from the PIV protocol that’s used for the CryptolD solution, YubiKey 
supports OTP and FIDO2 protocols, which is integrated with Cisco’s single sign-on service as an optional 
second factor authenticator 


Licensing and Maintenance Costs 


Setting up the dedicated environment (CMS, hardware, etc.) for Cisco cost approximately $250,000, 
which covered the first year of maintenance. In addition, Cisco paid around $20 per user per year for 
the “subscription” to the managed service. This totaled approximately $50,000 per year just for the 
Smartbadge program. 


The old managed service for AdminTokens was quite a bit more expensive, costing Cisco approximately 
$300,000 per year in licenses and maintenance. All of this and the Smartbadge cost were avoided by 
moving to our in-house, home-grown solution. 


Support Cases 


The comparison of number of support cases for the old AdminToken and Smartbadge system versus the 
new CryptolD solution with Yubikeys is shown in Table 2: Comparison of Support Case Metrics. While 
difference in number of cases is not very significant, the number of cases reduced significantly over time, 
especially in the recent months, as shown in Figure 5: Breakdown of CryptolD cases by Cisco Fiscal 
Quarter. 


The CryptolD has been more reliable and easier to adapt for the users and it saved Cisco time and money. 


Admin Token + Smart Badge 80-85 


CryptolD 60-65 
@@D Q2FY19 GMB Q3FY19 GB Q4FY19 a QIFY20 


Table 2: Comparison of Support Case Metrics Figure 5: Breakdown of CryptollD cases by Cisco Fiscal Quarter 
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Conclusion 


In this white paper we have presented the CryptolD solution that Cisco implemented to replace traditional 
smart cards with BYOT support. The rollout of the CryptolID program has resulted in reduced overhead 
and increased efficiency to manage the tokens and the digital identities. The best practices and lessons 
learned from this implementation can help other organizations that plan to implement a similar solution. 
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Appendix A: yubico-piv-tool and ykman Commands 


The CryptolD client provides a menu-driven interface for the users to interact with the tokens. The 
CryptolID CLI menu is shown in the image below. The initial version of CryptolD client used the yubico-piv- 
tool to interact with the Yubikey tokens. Since Yubico decided to consolidate their client development on 
the newer ykman® tool, a version of the CryptolD client has been developed to add support for ykman. 


Client Authentication fo isco Admins. 
lient Authentication and D ment Signing for 


Cisco l ° 
The cryptoid-client tool also supports initializing of the Yubikey One Time Password (OTP) applet for u 


se in authenticating to Cisco Duo (https://disco.cisco.com). 


to.cisco.com/cryptoid for e details. 


Encrypt/Decrypt operations) 


e current PUK) 
zhe current PIN) 
forgot and blocked the PIN. Requires the current PUK) 
forgot and blocked both the PIN and PUK) 
(OTP) Status 
(OTP) Init 


Select a command to 


Figure 6: CryptolD Client - Menu List 


This section provides detailed steps and the yubico-piv-tool / ykman commands implemented behind 
the scenes for each of the menu options in the CryptolD client. 


1. Create New CryptolD Request 


1.1 Verify Token Connection 
yubico-piv-tool -a list-readers 
ykman list 


1.2 Verify PUK Requirements 
NOTE: The yubico-piv-too! doesn’t provide a verify PUK function, so as a workaround, 
we use the change-puk method to verify 
yubico-piv-tool -a change-puk -P <PUK> -N <PUK> 
ykman piv change-puk -p <PUK> -n <PUK> 


1.3 Verify Management Key Requirements 
NOTE: The yubico-piv-too! doesn’t provide a verify PUK function, so as a workaround, 
we use the change-puk method to verify 
yubico-piv-tool -a set-mgm-key -k <Mgmt_Key> -n < Mgmt_Key> 
ykman piv change-management-key -m < Mgmt_Key> -n < Mgmt_Key> 


https://github.com/Yubico/Yubikey-manager 
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1.4 Verify PIN Requirements 
yubico-piv-tool -a verify-pin -P <PIN> 
ykman piv change-pin -P <PIN> -n <PIN> 
1.5 Generate Keypair 


yubico-piv-tool -a generate -k <Mgmt_Key> -s 9a --pin-policy=once --touch_policy=never -A 
RSA2048 -o <publicKey_output_file> 


ykman piv generate-key --pin-policy=once --touch-policy=never -a RSA2048 9a 
<publickey_output_file> 
1.6 Generate CSR 
yubico-piv-tool -a verify -a request-certificate -k <Mgmt_Key> -P <PIN> -s 9a --hash SHA512 
-| <publickey_output_file> -o <csr_output_file> -S <subjectDN> 
ykman piv generate-csr -P <PIN> -S <subjectDN> 9a <publickey_output_file> <csr_output_file> 
1.7 (Attest Request) 
yubico-piv-tool -a attest -k <Mgmt_Key> -s 9a -o <keyAttestion_output_file> 
ykman piv attest 9a <keyAttestion_output_file> 


2. Import CryptolID AdminToken/UserToken Certificate File 


2.1 Import Certificate File 
yubico-piv-tool -a import-certificate -k <Mgmt_Key> -s 9a -i <file_location> 
ykman piv import-certificate -v -m <Mgmt_Key> 9a <file_location> 
2.2 Change CHUID 
yubico-piv-tool -a set-chuid -k <Mgmt_Key> 
ykman piv set-chuid -m <Mgmt_Key> 
3. Import CryptolID SMIME P12 File 


3.1 Import SMIME Certificate File 


yubico-piv-tool -a import-key -a import-cert -k <Mgmt_Key> -s 9d -i <p12_file_location> -K 
PKCS12 -p <p12_password> 


ykman piv import-certificate -v -m <Mgmt_Key> -p <p12_password> 9d <p12_file_location> 
3.2 Change CHUID) 

yubico-piv-tool -a set-chuid -k <Mgmt_Key> 

ykman piv set-chuid -m <Mgmt_Key> 


4. Verify Token Certificates (Perform Test Sign/Verify and Encrypt/Decrypt operations) 
4.1 Test Sign and Verify 
NOTE: The ykman tool doesn’t provide a verify and sign function 
yubico-piv-tool -a verify-pin -a test-signature -s 9a -i <slotCert_output_file> -P <PIN> 
4.2 Test Encrypt and Decrypt 
NOTE: The ykman tool doesn’t provide an encrypt and decrypt function 
yubico-piv-tool -a verify-pin -a test-decipher -s 9a -i <slotCert_output_file> -P <PIN> 
5. Display Token Status 
yubico-piv-tool -a status 
ykman piv info 
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Change PUK (Requires the current PUK) 
yubico-piv-tool -a change-puk -P <current_PUK> -N <new_PUK> 
ykman piv change-puk -p <current_PUK> -n <new_PUK> 


. Change PIN (Requires the current PIN) 


yubico-piv-tool -a change-pin -P <current_PIN> -N <new_PIN> 
ykman piv change-pin -P <current_PIN> -n <new_PIN> 


. Unblock PIN (If you forgot and blocked the PIN. Requires the current PUK) 


yubico-piv-tool -a unblock-pin -P <current_PUK> -N <new_PIN> 
ykman piv unblock-pin -P <current_PUK> -n <new_PIN> 


. Reset Token (If you forgot and blocked both the PIN and PUK) 


yubico-piv-tool -a reset 
ykman piv reset -f 


10. One-time password (OTP) Status 


NOTE: The yubico-piv-tool doesn’t provide OTP functions 
ykman otp info 


11. One-time password (OTP) Init 


NOTE: The yubico-piv-tool doesn’t provide OTP functions 
ykman otp yubitop -G -g -S -f <slot> 


Appendix B: CryptolD Provisioning Request Data 


The CryptolD Provisioning Request Data is organized as a simple JSON structure with the following 
elements: 


userName: 
- Cisco userlD that was authenticated against AD to create the request 


tokenType: 


- Token Type 
csr: 
- Certificate Signing Request generated from keypair on token 
attestionData: 
- output from “attest” command given to Yubikey 
attestionSigner: 
- read from slot f9 of the Yubikey 


clientHeuristics: 
- userName, hostName, and hostAddress of the machine used to run the client 


Given below is a sample CryptolD Provisioning Request Data. 
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{ 
“username”: “ userid”, 
“tokenType”: “ Yubico YubiKey”, 
Ora BEGIN NEW CERTIFICATE REQUEST----- 


<csr data> 


“attestationData”:”----- BEGIN CERTIFICATE----- 


<attestation data> 


“attestationSigner”:” ---BEGIN CERTIFICATE----- 


<attestation signer data> 


“clientHueristics”: {“nostName”:”host1”, “hostAddress”:”192.168.1.193”, “userName”:”userid”} 


} 


Appendix C: OTP Registration Request Data 
The OTP Registration Request Data is organized as a simple JSON structure with the following elements: 
= userName: 
- Cisco userlD that was authenticated against AD to create the request 


= serialNumber: 
- Yubikey serial number 
= firmwareVersion: 
- Yubikey firmware version 
= deviceType: 
- Token Type 
= publicld: 
- First 12 characters of the string output by a Yubikey when pressing it 
=" privateld: 
- Can be accessed when an OTP is decrypted in a Yubico OTP validation server 


= secretKey: 
- The actual OTP seed value 


The entire structure is then encrypted using RSA/ECB/OAEPWithSHA1AndMGF1Padding to an RSA public 
key held by the registration portal. Given below is a sample OTP Registration. Request Data. 


White paper afiafi 
Cisco Public CISCO 


“deviceType”: “Yubikey 4”, 

“firmwareVersion”: “4.3.7”, 

“privateld”: “9e14c1c2850€”, 

“publicld”: “fetchchnkglk”, 

“secretKey”: “Seb089934ee7c27091cb89b39942e1a9”, 
“serialNumber”: “7050665”, 


», 


“userName”: “userid” 


Appendix D: Firefox Configuration for TLS Client Authentication 


1. Install OpenSC for your platform: 
o Mac - OpenSC 
o Windows - OpenSC 
2. Firefox has it's own store for certificates, so you need to tell it to look at your Yubikey as a "source". Go into Firefox Options/Preferences and the Privacy and Security tab: 


xt General 

M Home 

Q Search 

Ú Privacy & Security 


g Sync 
3. Scroll to the bottom and click on "Security Devices..." under the Certificates section: 


Certificates 
When a server requests your personal certificate 


Select one automatically 
@ Ask you every time 


Query OCSP responder servers to confirm the current validity of View Certificates... 
certificates 


Security Devices... 


4. Click "Load" (on the left) and add the following path appropriate to your platform: 
o Mac: /Library/OpenSC/lib/opensc-pkcs11.so 
@@©© __load PKCS#11 Device Driver __ 


Enter the information for the module you want to add. 


Module Name |OpenSC PKCS#11 Module Load 


Module filename enSC/lib/opensc-pkcs11.so Browse... 


Unload 
Cancel Enable FIPS 
o Windows: C:\Program Files\OpenSC Project\OpenSC\pkcs11\opensc-pkcs11.dil 


©@ Load PKCS#11 Device Driver - x 2 
Change Password 


Enter the information for the module you want to add. 


Module Name | OpensSC PKCS#11 Module Load 
Module ierame “owe. Unioad 
Enable FIPS 


[oT] et 
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Appendix E: VMware Configuration for dedicated Yubikey 


In order for the PIV protocol functions to work correctly with the YubiKey tokens on a virtual machine (VM) 
running on VMWare Fusion or VMWare Workstation, the Yubikey must be connected to the guest VM 

in dedicated mode. If it is connected in “Shared” mode, the VM will not detect the PIV slots. On some 
versions of VMware Fusion and VMware workstation, it is required to make some configuration changes to 
enable connecting the Yubikey in dedicated mode. 

To verify if you need these changes or not, check if you are getting an option to connect the Yubikey in 


dedicated mode to the VM as shown in the picture below (highlighted menu option). If you only see the 
option to connect in “Shared” mode, then try following the instructions in this section. 


Reinstall VMware Tools 
Install Virtual Printer 


Network Adapter 
Hard Disk (SCSI) 
CD/DVD (SATA) 
Sound Card 
Camera 

USB & Bluetooth 


pan cachacs USB-PS/2 Optical ite 
Connect Apple USB-C Digital AV Multiport Adapter 


USB & Bluetooth Settings... 


Figure 7: Connecting YubiKey in “dedicated” mode 


Follow these steps to make configuration changes needed to connect the Yubikey in dedicated mode to a 
Virtual Machine running on VMware Fusion or VMware Workstation 


1. Ensure the VMwere Tools are installed on the VM and power down the VM 


2. Check the Virtual Machine Details section in VMware Workstation / VMware Fusion and note where 
the Configuration file (vmx) is located, as shown in the image below. 


~ Virtual Machine Details 


State: Powered off 


Snapshot: MD not installed 
Configuration file: E:\Virtual Machines (VMware Workstation)\Server 2016\Server 2016.vmx 


Hardware compatibility: Workstation 11.x virtual machine 
Primary IP address: Network information is not available 


Figure 8: Location of the VM Configuration File 
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3. Open the VM configuration [virtualmachinename].vmx file in a text editor. 
4. Paste the below lines at the very end of this file and save the file. 
machine. usb.generic.autoconnect = “FALSE” 
usb.generic.allowHID = “TRUE” 
usb.generic.allowLastHID = “TRUE” 
usb.generic.allowCCID = “TRUE” 


Note: The first line (usb.generic.autoconnect) is optional but helps to prevent a VM from 
automatically grabbing the YubiKey from another VM, or the host itself, when the YubiKey is 
inserted. The remaining lines enable direct passthrough of the YubikKey to the guest VM. 


5. Power on the VM and once it boots up check if you are getting the option to connect the 
Yubikey in dedicated mode. If the changes are done correctly, you should now see an option 
to connect the YubiKey in dedicated mode (nonshared). 


Appendix F: Sample Token Selection Criteria Checklist Form 


A sample token selection criteria checklist form is provided here for reference. It includes excerpts from 
Cisco’s evaluation of Yubikey NEO and Yubikey 4 Series tokens. Note that this evaluation was conducted in 
early 2018 and the results are based on the features available at that time. 


Self-Provisioning-Related Requirements 


Support for PIV/Smartcard slots. Supported 

Ability to generate the private keys securely and directly on Supported 

the hardware token. 

Support for RSA 2048 or better Supported 

Private keys generated on the hardware token should be Supported 

NOT exportable. 

Slot PIN policies should be NOT updatable once the key is generated. Supported 

Ability to attest and verify that the private key was generated on Supported in YubiKey 4.3 and newer 


the hardware token. 


Ability to attest and verify that the PIN policies for the slot where Supported in YubiKey 4.3 and newer 
the private key is generated. 


Ability to attest and verify the device SN, model/firmware version Supported 
of the token on which the key/CSR is generated. 


Ability to create a CSR using the private keys created in the Supported 
hardware token. 


Ability to import externally signed certificates to the slot that has Supported 
the associated private key. 


Support for multiple slots Supported 
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Smartcard Logon-Related Requirements 


Smartcard Logon to Remote Windows Servers using Works only in Windows. The Remote Desktop 
Remote Desktop Client Client for Mac doesn’t support Smartcard logon. 
Smartcard pairing to local user account on Mac Supported 

Smartcard pairing to local user account on Windows Supported 


TLS Certificate-Based Authentication-Related Requirements 


Certificate Based Authentication to Websites on MacOS Works in Safari, Chrome and Firefox with OpenSC 
installed. In Firefox OpenSC PKCS11 module should 
be loaded for this to work. 


Certificate-Based Authentication to Websites on Windows Supported 


SMIME Email Signing Using the Certificate in Yubikey 


Email Signing on MacOS Works in Microsoft Outlook with OpenSC installed. 


Email Signing on Windows Works in Microsoft Outlook 
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